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Mission  Thread  Workshop  -  Goai 


Build  and  Augment  a  set  of  end-to-end  System  of  Systems  (SoS) 

mission  threads  with  quality  attribute  and  engineering  considerations 
with  the  stakeholders 


Capture  at  each  step  of  the  mission  thread 

•  the  engineering  considerations  from  diverse  stakeholders 

•  the  quality  attribute  concerns  associated  with  the  mission  thread 

•  the  applicable  use  cases  for  the  constituent  systems 

Develop  technical  challenges  associated  with  the  threads,  and  to 
aggregate  the  challenges  over  a  number  of  MTWs 

Outputs  will  drive  SoS  and  System/Software  Architecture  Decisions. 
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Air  and  Missile  Defense  (AMD)  OV-1  Example 


Protect 


Forces  Afloat 


Defend  HVA 


STRATCOM/ 


Gamma 


Carrier  Strike  Group 


Surface  Action 


COCOM/ 


JFACC 


JFMCC 


C2BMC 


Mission  Thread  (Template) 


Steps 

(15-25) 


Quality 

Attributes 


(5-10) 


Thread 


Assumptions 


Two  ships  (Alpha  and  Beta)  are  assigned  to  air  and 
missile  defense  (AMD)  to  protect  a  fleet  containing 
twn  hinh-valiift  assets  fHVA^  in  a  .Inint  Task  Fnrr.o 


1 .  Our  ship  Alpha  has  the  lAMD  commander  on-board 

2.  An  AMD  plan  involving  all  assets  is  in  place 


Description 


Engineering 

Considerations 


A  National  satellite 
detects  the  firing  of  a 
BM 


The  ADC  is  cued 


-2 


The  satellite  sends 
the  horizon  crossing 
point 


The  ADC  prepares  a 
radar  spot  search  at  the 
crossing  point 
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Mission  Thread  (details) 


Thread 


Steps 


Quality 

Attributes 


Assumptions 


Quality 

Aspect 

Comments 

Performance 

Bandwidth 

During  high  tempo  periods 
prioritization  of  usage  must 
be  imposed 

Availability 

Recovery 

This  capability  must 
recover  from  a  single  point 
of  failure  within  .x  sec. 
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Use  Case  Pointer 


Thread 


Vignette 


Assumptions 


Steps 


Quality 

Attributes 


Use  Cases  (  Built  as  follow-on) 


Node  1 

Node  2 
Nodes 
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Process 
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Numbers  to  Date 


Client  Description 


#  MTWs  #  Vignettes  #  Mission  #  of 

Threads  stakeholders 


IRAD  New 
platform/capability 


New  Naval  Ship  13 


Battle  Command  6 


Maritime  Detection  2 


NSF 


Air  Force  Program 


DHS 
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Lessons  Learned 


MTW  Phases 

•  Preparation 

•  Execution 

•  Follow  On 

SoS  Challenges 
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Preparation  Activities 


•  Scope  the  series  of  MTWs  to  satisfy  operational  coverage 
needs 

•  Develop  OV-1  diagrams  and  vignettes  for  the  operational 
capabilities 

•  Develop  step-by-step  description  of  activities  (threads)  in 
response  to  a  set  of  stimuli  for  the  vignettes 

•  Develop  a  set  of  architectural  quality  attributes  for  the  vignettes 

•  Determine  the  stakeholders  to  attend  each  MTW 

•  Identify  the  planned  use  of  legacy  systems 
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Preparation  Lessons  Learned 


•  OV-1  (or  a  user  story)  is  crucial 

•  AoA  and  User  Story  documents  are  a  good  source 

•  MTWs  served  to  normalize  the  different  OV-1’s  capabilities 

•  Assumptions  are  a  key  part  of  the  template 
Focus  is  on  SoS  capabilities,  activities,  and  QAs 

•  Software  is  critical,  but  implicit 

Initial  coaching  and  oversight  needed  to  build  the  threads 

•  Leads  for  later  workshops  attended  earlier  workshops  and  developed 
VERY  good  vignettes/threads 

•  Threads  should  be  well  vetted  prior  to  workshop 

15  to  30  steps  are  typical  for  each  mission  thread 

•  Operational  thread  often  needs  associated  planning  thread 

•  Time  period  of  a  thread  can  be  from  minutes  to  days 
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Conducting  Workshop 


Activities 

•  Briefings  on  the  operational  challenges  and  the  workshop 
intent  and  description 

•  Augment  the  thread  template  for  engineering  considerations 
/  QAs  /  Use  Cases  with  each  step 

•  Augment  the  QA  template  adding  over-arching 
considerations 
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Conducting  Workshop  -  Lessons  Learned 


If  there  was  no  planning  thread,  planning  assumptions  and  perhaps  a  step  1  or 
a  new  thread  will  have  to  be  added 

Don’t  mix  operational,  developmental  and  sustainment  threads 

First  thread  takes  3  to  4  hours,  following  threads  take  less  time 

Only  a  few  added  steps  were  needed  typically  (for  a  well  vetted  thread) 

Some  poorly  vetted  threads  required  more  changes  to  the  steps 

Listen  to  the  warfighters,  engineers  can  get  the  thread  wrong 

Work  initially  with  a  small  group  then  work  to  get  confidence  (pilot) 

Strong  third  party  facilitation  allowed  operational  principles  to  discuss  rather 
than  defend 

Diverse  operational  experiences  eliminate  stovepipe  mentality 
Dialogue  between  stakeholders  was  illuminating  to  all 
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Follow-on  Activities 


Facilitation  team 

Form  a  table  of  challenges  (5  to  7)  with  pointers  to  MTW 
steps/QA/assumptions 

Build  a  briefing,  one  page  per  challenge 

•  Description,  evidence,  impact  and  recommendations 

•  Keep  the  pointers  and  put  the  major  points  in  the  Notes  Page 

Vet  and  update  each  challenge  with  the  clients  and  the  leads 

Lessons  Learned: 

•  As  many  capability  /  engineering  gaps  and  challenges  as  architectural 

—  Clients  corrected  domain  specific  misunderstandings 

•  Avoid  rolling  up  too  much,  it  can  become  meaningless 

•  Need  actionable  recommendations  for  challenges. 
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SoS  Quality  Attributes 


Quality  Attributes  of  interest  depend  on  vignette/thread  type 

•  Operational  :  performance,  availability,  security,  interoperability 

•  Developmental:  legacy  reuse,  extensibility,  openness,  integrability 

•  Sustainment :  maintainability,  training,  deployability,  upgradeability 


New  consideration  examples 

•  Survivability:  Machinery  MT  on  how  to  contain  compartmental  flooding 
in  a  critical  compartment  resulted  in  discussion  on  using  new  pump 
technologies  to  avoid  flooding. 

•  Availability:  Machinery  MT  on  failure  of  a  generator  has  a  massive 
impact  on  all  ship  operations  and  mission 

•  Availability:  Degraded  operation  on  a  failure  needs  to  be  defined  across 
echelons,  and  mitigation  alternatives  defined 

•  Reduced  Manning/Automation 
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Challenge  Rollup  Across  SoS  Clients 


# 

Name 

#  Clients 

1 

Usability/Automation 

3 

2 

Capability  Gaps 

4 

3 

Resource  Management 

4 

4 

Training 

3 

5 

Legacy  Migration 

3 

6 

Collaboration 

4 

Recommendations  not  rolled  up  for  this  presentation 
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Usability/Automation 


Each  system  has  its  own  “Look  and  Feel”  and  a  common  “look  and 
Feel”  must  be  developed  using  a  common  toolkit,  graphics  and 
icons. 

•  There  is  a  lack  of  “grunt-work”  automated  support  and  tool 
integration  for  many  critical  processes  used  by  the  warfighters 

Human  Factors 

•  The  cognitive  burden  on  the  warfighters  must  not  overwhelm  them 

•  In  order  to  support  “reduced  manning”  we  need  more  automation 

•  Both  operational  and  sustainment  (field  service  engineers) 

•  Alert  management  requires  root  cause  analysis 
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Capability  Gaps 


Omissions 

•  Aircraft  as  communication  relay,  as  well  as  sensors 

•  Data  collaboration  to  reduce  classification  time 

Situational  Awareness 

•  Engagements  can  last  for  hours,  the  warfighters  need  360°  Awareness 

Multi-Mission  Planning 

•  Distributed/collaborative  planning  -  overlapping  time  periods 

Demonstration  Omissions 

•  Effectiveness  called  into  question  because  of  missing  critical 
capabilities 

End-to-End  Modeling  and  Simulation  was  under-played 
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Resource  Management 


Individual  systems  had 

•  Low  operational  reliability 

•  Have  to  re-build  Situational  Awareness  state  after  recovery  from  failure 
Disconnected  operations  poorly  defined  and  managed 

Degraded  modes  of  operation  inconsistently  defined  within  SoS 

•  Impact  of  loss  of  FCQ  track 

Distributed  Resource  Manager  could  not  map  from  large  scale  failure 
to  impact  on  current  missions  to  suggested  recovery  strategies 
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Training 


Training  system  has  capability  gaps 

Operator  proficiency  degrades  between  assignments,  but  no  re¬ 
training 

Need  lightweight  simulations  on-board  for  embedded  training  and 
mission  rehearsal 

New  “Look  and  Feel”  will  cause  extensive  re-training 

Maintenance  and  training  considerations  are  not  sufficiently  well 
defined  for  the  support  systems  to  be  well  architected 
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Migration  of  Legacy  Systems 


Current  stovepiped  systems  will  have  trouble  migrating  to  a  COE,  and 
both  FMS  and  weapons  safety  certification  further  complicates  this 
effort. 

Each  stovepipe  has  its  own  data  architecture  for:  data-at-rest,  data-in- 
transit,  and  external  interfaces.  The  Architecture  Team  will  have  to 
determine  commonality  (and  differences)  between  the  information 
being  used,  and  formulate  common  data  structures. 

Each  stovepipe  use  different  development  environments  and  tools, 
have  different  CCBs,  integration  and  test  environments, 
development  processes  and  different  backward  compatibility 
strategies. 
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Collaboration 


There  is  little  automated  support  for  geographically  distributed,  cross¬ 
echelon  efforts  to  classify  tracked  objects 


Mapping  the  external  interoperations  semantically  to  the  missions 
being  planned  or  conducted  is  inadequate 


Cutoff  between  manual  and  automated  management  of  the  fight 
involving  many  incoming  missiles  is  not  defined 


The  strategy  to  move  currently  stovepiped  systems  to  a  COE,  and  to 
deploy  across  to  multiple  echelon  TOCs  and  platforms 
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Next  Steps 


Acquisition  Strategy 
Developmental  threads 
Courses  to  support  training  needs 
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Summary 


Can  augment  end-to-end  threads  with  QA  considerations 
Identifies  SoS  challenges  early  (very  good  risk  predictors) 
Cross-discipline  stakeholders  can  agree  on  thread  steps 

•  Reduce  “rice-bowls”,  identify  “long  poles” 

Good  facilitation  is  necessary 

•  Enough  patience  to  hear  things  through 

•  Enough  control  to  move  things  along 

Approach  can  be  easily  tailored  and  has  been  used  for  an 
Enterprise  Service  context 

A  core  team  for  MTW  facilitation  and  SoS  stakeholders  provided 
consistency 
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